REMARKS 

Reconsideration of the present application is respectfully requested. No claims 
h#ve been amended, cancelled or added in this response. No new matter has been 
added. 



Ol gjm Rejections - §1 03(a) 

Claims 1-3, 5-6, 8-14 and 16-21 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over U.S. Publication 2002/0056126 of Srikantan et al. (hereinafter 
« sr jkantan"). 

An object of Applicants' invention is to reduce bursts in streaming media data 
traffic, in order to reduce congestion of downstream routers, servers, etc., particularly 
when a large number of clients have requested the same media data stream at 
substantially the same time. Such congestion can result in degradation in the quality 
and smoothness of the data streams that are ultimately delivered to the clients. 

In contrast, Srikantan's main purpose is to more economically manage resource 
con sumption (e.g., CPU, memory, etc.) on the streaming server in relation to per-track 
me tadata. Srikantan does not address the problem of reducing burst traffic or of 
reducing congestion in downstream network nodes generally. 

In particular embodiments of the present invention, congestion in downstream 
nodes is reduced by reducing streaming media burst traffic, and more specifically, by 
adding to each packet's specified delivery time a delay value that has been pseudo- 
ran do mlv selected for each client. This technique virtually ensures that even if a large 
nurn ber of clients (e.g., 10,000 or more) request the same data stream at the same 



2 



time, there will not be a large number of clients assigned the exact same delivery time 
for a given data packet. This technique, therefore, has the effect of spreading the 
delivery times of a given data packet for multiple clients substantially evenly throughout 
a given time window, thereby reducing burst traffic. With the above remarks in mind, 
attention is directed to independent claim 1. 
Claim 1 recites: 

1 . A method for reducing magnitudes of output traffic bursts in a streaming 
media cache, comprising: 

receiving a request from a first client system for a stream of media data, 
the stream of media data including a first streaming media data packet and a 
second streaming media data packet; 

receiving a request from a second client system for the stream of media 

data; 

receiving the first streaming media data packet from an upstream server, 
the first streaming media data packet including a delivery time; 

pseudo-randomly selecting a first delay value and adding the first 
delay value to the delivery time of the first streaming media data packet to 
form a first modified delivery time for the first streaming media data packet; 

pseudo-randomly selecting a second delay value and adding the 
second delay value to the delivery time of the first streaming media data 
packet to form a second modified delivery time for the first streaming 
media data packet; 

modifying the first streaming media data packet with the first 
modified delivery time to form a first modified first streaming media data 
packet; 

modifying the first streaming media data packet with the second 
modified delivery time to form a second modified first streaming media 
data packet; 

outputting the first modified first streaming media data packet to the first 
client system at the first modified delivery time; and 

outputting the second modified first streaming media data packet to the 
second client system at the second modified delivery time. 
(Emphasis added). 

In contrast, Srikantan does not teach or suggest the above emphasized 
limitations. The Examiner acknowledges that Srikantan does not explicitly disclose 
modifying a media data packet's delivery time for first and second client respectively 
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(Final Office Action mailed on 1 1/17/2006, page 3). The Examiner, however, alleges 
that Srikantan discloses media frames of a live or pre-recorded event from a single 
source being simultaneously streamed in a real-time to multiple users in a specified 
order within a certain period of time. The Examiner further alleges that time delay 
techniques are utilized in order to deliver the packets of a single live or pre-recorded 
transmission to multiple clients as described by Srikantan. In order to support the 
above allegation, the Examiner cites Srikantan's paragraphs 25, 26, 55 and 56, and 
alleges that "different time indices" disclosed in Srikantan reads on the first and second 
delay values recited in claim 1. The Examiner then concludes that it would have been 
obvious to one with ordinary skill in the art to understand that the method disclosed in 
Srikantan involves modifying the media data packet's delivery time belonging to single 
media source in order to accommodate simultaneous real-time transmission to multiple 
clients. Applicants respectfully disagree. 

As disclosed in Srikantan, a "time index" (or "time indices") is completely different 
from a delay value such as recited in claim 1 . A time index is used for determining 
where a segment is located in a track or media file (see paragraph 3 and claim 17 of 
Srikantan). In other words, time index identifies and locates a media segment's time 
position in a track or media program (see Abstract). Thus, metadata regarding time 
indices is used to make sure a media track or file is streamed in the correct sequence 
with appropriate timing (see paragraph 3). 

In addition, "delivery of each frame or other unit of the media must be performed 
in a specified order and within a certain period of time" (alleged by the Examiner and 
disclosed in Srikantan's paragraph 26) does not require time delay techniques to be 
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used. A media segment with a specified time index within a track or media file is 
supposed to be delivered at the specified time index, not because it is delayed to be 
delivered at the specified time index. 

Srikantan's paragraph 55 states that "the same media may be streamed to each 
client, but with different timing." However, paragraph 55 further explains that the above 
quoted language means that "different client streams may, at any given time, be 
streaming media from different time indices within the media track." In other words, the 
above quoted language means that different clients are streaming different segments of 
the media track (because different time indices identify different segments), not that a 
first and second delay values are used to modify the delivery time of a same data 
packet to different clients. A person with ordinary skill in the art cannot reasonably 
conclude that the method disclosed in Srikantan involves or even suggests modifying 
the media data packet's delivery time to deliver the data packet to multiple clients. 

For at least these reasons, therefore, claim 1 and all claims which depend on it 
are patentable over Srikantan. 

Independent claims 9 and 16 include limitations similar to those discussed above 
for claim 1. Therefore, claims 9, 16 and all claims which depend on them are also 
patentable over Srikantan. 

Conclusion 

For the foregoing reasons, the present application is believed to be in condition 
for allowance, and such action is earnestly requested. 

If there are any additional charges, please charge Deposit Account No. 02-2666. 
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